在鐵人賽「Build on Google AI Track」的倒數第二篇，我們將進行一次深入的幕後揭密。要在短短 30 天內，從無到有打造出一套包含 FullCalendar v6 互動前端、Google Apps Script (GAS) 後端、Telegram Bot 即時推播 與 自動化自我修復機制 的產品級 NGO 房間預約系統，單靠個人在有限時間內是極大的挑戰。

這次的開發之所以能夠高效達標，核心在於採用了 AI 協同開發範式（AI-Assisted Development）。今天我們將詳細拆解本專案的 Prompt 工程技巧、規格驅動開發（Spec-Driven Development） 流程，以及 Gemini 如何在各個模組中扮演最強的技術協作者。

1. 規格驅動開發 (Spec-Driven Development) 與上下文管理

在與 AI 協同開發大型應用時，最怕遇到「片段、不連貫且前後矛盾」的程式碼。為了避免這種狀況，本專案建立了一套嚴謹的 四階段協同工作流：

[ 1. 專案邊界與架構錨定 ] ──► [ 2. 模組化規格定義 (SRD) ] ──► [ 3. 程式碼生成與整合 ] ──► [ 4. 例外處理與自我修復 ]

🔑 核心 Prompt 工程三大心法

1. 嚴格的邊界與負向提示（Negative Prompts）：

• 在對話初期，明確告知 AI 系統的設計紅線。例如：「明確排除管理員手動審核，預約採即時自動核准；Telegram 推播中嚴禁顯示租賃費用，保護職工隱私。」這能有效防止 AI 憑空生成不符合業務邏輯的冗餘功能。

2. 軟編碼架構的強制約束（Soft-coding Constraint）：

• 在要求 AI 生成業務邏輯（如 BookingService.gs 或 CancellationService.gs）時，強制要求所有參數必須從 Config.gs 讀取，拒絕寫死任何房間名稱、費用或時間限制。

3. 模組化迭代（Modular Iteration）：

• 將 30 天的開發拆解為 11 個獨立的微服務檔。每次對話只聚焦於一個特定模組的實作與測試（例如：「今天我們專注於實作 QR Code 簽到與 15 分鐘逾時釋放機制」）。

2. Gemini 在三大核心模組的實戰對話與應用

以下展示 Gemini 在本專案中發揮關鍵作用的三個最具代表性的實戰場景：

🛠️ 實戰場景 A：設計 Google Sheets 資料庫與軟編碼設定檔

• 人類工程師的 Prompt 策略：

「我們正在為 NGO 開發房間預約系統。請設計一個軟編碼的 Config.gs 結構，包含 5 個指定房間（活動室 A1/A2、B1/B2、洽談室）、每日 08:00-22:00 營運時間、30 分鐘為單位的時段切割，並定義對應的 Google Sheets 工作表 (Bookings, SystemLogs) Schema 欄位。」

• Gemini 的產出與貢獻：
  Gemini 不僅輸出了清晰的 JavaScript 鍵值對配置，還主動規劃了 Bookings 表格所需的 10 個標準欄位（包含 BookingID, UserEmail, RoomID, StartTime, EndTime, Status, CheckInTime 等），為後續的 QR Code 簽到與狀態追蹤鋪平了道路。

🎨 實戰場景 B：前端 FullCalendar v6 與 Tailwind CSS 介面生成

• 人類工程師的 Prompt 策略：

「請撰寫前端 Index.html，使用 FullCalendar v6 結合 Tailwind CSS。頁面頂部需提供房間切換下拉選單。當使用者點選行事曆空白時段時，透過 google.script.run 非同步調用後端 getAvailableSlots，並跳出 Modal 讓使用者填寫 Email 與用途。請確保程式碼具備防呆機制，避免職工重複登記已佔用的時段。」

• Gemini 的產出與貢獻：
  Gemini 產出了高品質的單頁前端介面，妥善處理了 FullCalendar 的時區轉換、事件點擊回調（Event Click）以及非同步載入的 Loading 狀態，讓前端與 GAS 後端無縫對接。

⚙️ 實戰場景 C：複雜的商業邏輯與防禦性編程 (CancellationService.gs)

• 人類工程師的 Prompt 策略：

「請撰寫 24 小時取消規章的後端邏輯。當職工申請取消時，需比對目前時間與預約開始時間：若大於等於 24 小時，狀態更新為 CANCELLED（免罰則）；若小於 24 小時，狀態更新為 LATE_CANCELLED（記錄晚取消違規）。最後呼叫 TelegramBotService.gs 發送 HTML 格式的異動通知，並全程包裝在 Try-Catch 中。」

• Gemini 的產出與貢獻：
  Gemini 運用了 GAS 的 Utilities.formatDate 與精確的時間戳差值運算，產出了邏輯嚴密且具備防禦性（Defensive Programming）的取消服務程式碼。

3. 人機協作的避坑指南與 Best Practices

在歷時 30 天的協同開發中，也歸納出幾項與 Gemini 共同開發 GAS (Google Apps Script) 專案時的寶貴經驗：

• 注意 GAS 的 API 限制：GAS 與標準 Node.js 環境不同，部分第三方套件無法直接運走。提示 AI 時應強調「必須使用 Google Apps Script 原生服務（如 UrlFetchApp, SpreadsheetApp, ScriptApp）」，以減少語法幻覺。
• 持續更新 Active Context：隨著專案推進，每次開啟新對話時，先提供一份精簡的「目前專案架構總覽與已完成模組清單」，能確保 Gemini 產出的新程式碼完美契合既有程式碼的函數命名與架構風格。

4. 小結與最終章預告

今天我們進行了 AI 協同開發實戰：我如何用 Gemini 完成這套系統的 30 天速成，回顧了 Prompt 工程與規格驅動開發的實際威力。

明天結局篇，不容錯過！